Understanding the engine

The Nilkins Engine is composed by components. Each of them will provide different functionalities that can be used together or not.

Each component has a position in the ecosystem. It could be represented by something like :

Level 0 nkLog nkExport
Level 1 nkResources nkTasks nkMaths nkMemory
Level 2 nkInputs nkScripts nkWinUi nkImages
Level 3 nkGraphics
Level 4 nkAstraeus

A component higher in the hierarchy can rely on one or more components from the lower levels. For instance, the nkTasks component uses the nkLog component. Or nkScripts uses nkExport, nkLog and nkResources.

For a more detailed description for each of them :

Component Description Dependencies
nkLog Common logging interfaces among the components -
nkExport Abstraction over exporting capabilities, such as Json... -
nkResources Offers functionnalities to centralize path management nkLog
nkTasks Helps with asynchronous work scheduling nkLog
nkMaths Offers all needed mathematics functionnalities for the components nkLog
nkMemory Offers memory handling capabilities, through pools, pagers... nkLog
nkInputs Abstracts input devices and capabilities nkLog, nkMaths
nkScripts Allows for scripting environment setup nkLog, nkExport, nkResources
nkWinUi Offers ways to create system UIs nkLog, nkExport, nkResources
nkImages Offers image formats encoding / decoding capabilities nkMaths, nkMemory
nkGraphics Abstracts graphics API usage for graphical work nkLog, nkExport, nkResources, nkTasks, nkWinUin, nkMemory
nkAstraeus Leverages all other components to offer higher level access to the engine nkLog, nkGraphics, nkScripts

Dependencies

The engine uses some third-party code :

General optimizations

The binaries packed into the archive come from the release configuration. While the engine is designed to be usable by any project configuration (debug, release...), some safeties can be disabled to optimize further the client build.

Devirtualization : NK_ALLOW_DEVIRTUALIZATION

To avoid the compilers taking shortcuts and ignoring exported destructors for virtual classes designed as final, some classes are safe-guarded. Such classes are declared as final using the NK_FINAL keyword. By default, the keyword will hide that a class is final to the client compiler, to avoid any issue.

However, by defining the NK_ALLOW_DEVIRTUALIZATION preprocessor flag in the project settings, it is possible to disable this behaviour to have the classes properly seen as final. This will make the compiler properly take the shortcuts it wants to take.

This flag can generally be activated in any release configuration when using the engine. However, if any crash starts to happen when destructing an object coming from the engine, it means that this flag should not be activated.